| Discussion Leader | Topic | Discussion |
|---|---|---|
| Chairs | Status and Agenda Bash | Not using Softarmor site to
track drafts (other tools good enough). New process on WGLC reviews, assignments, etc. Please talk about this on mailing list. Updated charter, including WGLC dates. Lots of milestones, aggressive but doable (two slides of milestones by yearend). New items? SBCs, Race conditions, overload, and offer-answer. Agenda bashing? IETF consensus at Dallas was we are too spread out, so don't want to have slots without discussions. (discussion at end of session follows) Will work on triggering review deadlines, pinging volunteers. Tracker for issues, like ECRIT? Cullen - Have lots of experience with a lot of trackers. let's get this right. Robert - Bugzilla not right for comment tracking. |
| Dan Petrie |
Config Framework |
draft-ietf-sipping-config-framework-08.txt draft-ietf-sipping-xcap-config-00.txt draft-ietf-simple-xcap-diff-03.txt Have pending drafts on sipping-config and xeap-config. Just recognized requirement to make sure server supports XCAP. Have gotten clarifications and comments from reviewers (thanks). Added HTTP header Event statement to IANA section. Henning - any restriction on use of this? "Please send SIP event" - it's the URL to retrieve the profile. Jonathan had pointed out previously that "document" refers to entire document, not partial docoments - added normative text for this. Updates to local profile, error for "Profile Indicated By Constraints Does Not Exists" (404). Documented concept of filtering using profile-type, document, auid. 489 response for "does not support XCAP" ("Bad Event"). Adam - this isn't the way 489 is usually used - will send e-mail about this, but need to sit down and think about this first. Jonathan Rosenberg - "parameters are effectively filters". Not a 489, it's something else, needs a new response code. Multicast discovery mechanism proposed - add to draft, or make separate draft? Rohan - if you have concrete text that works, put it in the document, otherwise separate draft if it's not ready yet. Henning - overlap with P2P-SIP using Bonjour-style discovery. Do this separately and address a bigger problem. Cullen agrees - anything we can separate out, we should separate out to avoid holding up documents. network-user and SUBSCRIBE text is at SHOULD strength - ought these to be MUSTs? Henning - general comment, SHOULD is cop-out unless you have specific conditions why it's not a MUST. State as conditional compliance. Mary - SHOULD should have conditions. Francois - issue with SHOULD is that this is a phone thing, and people take every shortcut with phones. Martin - prefer MUST but agree with Henning. Event package provides mechanism to confirm the new profileis received - confirm that profile was applied? Cullen - this is easily separable. Devices don't do this today. Jonathan - is someone worried about this? Where did request come from? Martin - applies to device profile, doing a download to correct a problem and would like to know that problem should be corrected. This is Dan's experience as well. Jonathan - it's reasonable, but feels like SNMP TRAP, and one of many things we probably need. WGLC of next versions? Mary - submit edits you have now? Could finish these new edits up this week. Will recruit volunteers for LC reviewers of next version. |
| Gonzalo Camarillo | Consent Framework |
draft-ietf-sipping-consent-framework-05.txt
draft-camarillo-sipping-consent-format-01.txt draft-camarillo-sipping-pending-additions-00.txt Removing complex REFER by restricting to one URI at a time. Adding optional event package for permissions. Now using MESSAGE instead of CONSENT request. Two parts - XML and human-readable. Rohan - both optional? Yes. Defined a permissions server for storing your permissions while you are offline (actually stores IMs). Don't need to define retrieval protocol because this is the same as receiving document when you're online. PUBLISH permission grant does not need to contain document - HTTP optional. Framework is simpler than last time. Ben - have deprecated use of MESSAGE for computer-to-computer? This is actually intended to be intended to a person. Jonathan - two pieces of data, one human-readable, other is permission document that automata could process. Need store and forward, reinventing IM, just reuse IM... Ben - we've come down on the other side previously, this is on the border. But remember store-and-forward is not part of the standard and people have implemented it in different ways. Gonzalo - understood, and commented in the draft. Rohan - appropriate, even second body part eventually rendered to user. Has much simpler call flow than previously. Open issues... "Pending additions" URI? follow model used in conferencing? Removing "request contained URI-list" - request permissions directly. Will do this in next revision of the draft. Return 409 ("Forbidden") for attempts to add more than one URI at a time. Do we need to define a Permission Server, or is this just "store-and-forward" server? Andrew - If I change service providers, so I have to change permissions? Jonathan - are you talking about your buddy list? Permission server has nothing to do with that. As long as you have permissions to add to your buddy list, you're fine. Rohan - 409 conflict will be defined in this document? Jonathan - framework introducing a new constraint, consent-derived. Document in 409 body says what you don't like. This is an extension to SIMPLE framework that we've already defined. Discuss in SIMPLE? But everyone is hear anyway... Jonathan - very sleepy discussion, what happens if people wake up and say it's still too complicated? Who likes it? Who read the draft? We need to be done with this. (Fair amount of readers). Cullen likes, Henning likes. Do all three need to be working group items? Framework is normative - goes to SIP or stays in SIPPING? Will talk to ADs and SIP chairs. |
| Volker Hilt | Session Policies |
draft-ietf-sipping-session-policy-framework-01.txt draft-ietf-sipping-policy-package-01.txt draft-ietf-sipping-media-policy-dataset-01.txt Submitted as WG drafts, editorial changes, IANA considerations improvements, Security Considerations improvements. Added architecture diagram, mandated support for Media Policy Data Set. Added an optimization for local session descriptions (remove messaging overhead and message size). Removed PUBLISH/SUBSCRIBE alternative from draft (last major open issue). Presentation included call flow... Would like feedback - not many people people in the room have read the draft. Gonzalo - have call completion package doing similar things with SUBSCRIBE - would like to discuss this (and discuss this once), make sure people are awake. Rohan - we agreed to this in Vancouver, shouldn't surprise someone. Paul - this is the slippery slope. Changing what you're putting in the SUBSCRIBE, not establishing a filter, this is turning into an RPC - state doesn't really happen (most of the time, anyway). Gonzalo - want to make decision and move forward, right? Mary - can't hum with four people, will follow up on the mailing list, but we do need feedback and reviews. Keith - need to discuss SIP/SIPPING, right? Cullen - Jon and I think this needs to go to SIP. Event pakage has also been submitted as WG item. New Examples section with call flows and message details, "local-only" event header for NOTIFYs. Open issues.... Format for SUBSCRIBE and NOTIFY bodies? SDP? Can't express everything, requires MIME/MULTIPART, UA must support modified SDP announcement. XML-based Media Policy Dataset? Lots of advantages, but more complex, requires UA to parse and generate XML documents. What information should a UA submit to the policy server? SDP announcement? basic set of elements? We have some elements, need some more (media addresses and ports). Proposal is to use XML-based Media Policy Dataset and extend the Media Policy Dataset. Race condition here? would be specified in the draft. Mary - will review companion documents to make sure these make sense. |
| Robert Sparks | Multiple Dialog Usages in SIP | draft-ietf-sipping-dialogusage-02.txt Draft is getting significant comment on the list, pretty much done. Putting in text on effect of forking, changing recommended effect of 403. Have conflicting normative text on where to send NOTIFY? "Don't do this", but older devices work this way - how to move forward? Rohan - don't think this problem really exists if I start dialog with INVITE and then SUBSCRIBE? If you SUBSCRIBE before INVITE completes, yes. Does anyone else think this is not a problem? Point is that we need to pick an interpretation and write it down - or not... Paul actually has a scenario - reinvite that fails. Keith - if you get cases of problems we don't want to solve, can we clearly document them while walking away? Jonathan was out of the room ... and now remembers why he hates dialog reuse ... but there is a single-dialog fail, too. Aren't these things supposed to be processed atomically? Hard for implementers to transition BACK to A' remote target. "If it hurts, don't update in provisional response". Some people have desktops that PRACK and then handoff to another device - this problem does matter. Next steps - finish 100rel discussion, publish this document, build normative changes list, execute the list. Can we do UPDATE instead of RE-INVITE, and bypass all of this? Rohan sees no problem. 3GPP2 call flows use reliable provisionals instead of RE-INVITEs. Paul - used to think provisionals happened quickly, but now seeing much longer delays in some scenarios. Know we hit 3261-2-5. Put together a single document that goes through SIP and updates anything that we identify. Keith - will make a proposal on bug fixes in SIP. Is there any guidance on documenting new status codes? Robert meant to write this down - did I? Did Jonathan? No one remembers - need to check! Paul - lots of SIP fixes here, race conditions and offer-answer, other stuff in Bugzilla... where are we going? |
| Martin Dolly |
Potential Future BOF on Call Usage in SIP | Goal is to ensure service
interoperability across heterogenous networks. Changes to core SIP goes to SIP/SIPPING. Dean doesn't want to have a license to publish P-headers - Martin thinks BCPs, then Event packages, only then P-headers. "Core SIP" is Hitchhiker's Guide definition. .... "SIP 16" problem (Adam?) Eric - would prefer that we do this. Half the people in the working group don't care. Jonathan - features are hard, and need to look at this closely. Keith - not about this group existing, but about whether guidelines are correct or not. That discussion should not happen in this context, but in a wider context. Cullen - we're still in the context of the SIP change process. Keith - people say "we want to do this, and we need a P-header", and the response is "even if it's a P-header, it needs wider review" - that's the conversation shouldn't be having here. See this done all the time in other forums, obviously valuable, should be done. Mary - needs to happen in a lot more constructive way. Dean - problem is that P-headers may reveal broken SIP concepts that need to be fixed, not band-aided over in isolation. Gonzalo - P-headers are reviewed in SIPPING anyway, right? and not in this group? Jonathan - charter should exclude P-headers and focus on solving in general manner. Francois - goal here is to have fewer P-headers, not more, right? Good forum for heading these off. Keith - process requires search for general problem. Paul - the problem is that the P-header request is the tip of the iceberg. Adam - Francois is right, shouldn't even be doing these in the IETF. Proposed charter at www.sip-voip.org. 90-100 participants now. Planning BOF at San Diego, revisitng group name. Have uncomitted candidate services list to start with. Cullen - San Diego is a long ways away, but not really when you back off the deadlines, and we're moving the deadlines forward a week or two for better IESG/IAB interaction on BOFs. |
| Discussion Leader | Topic | My
Notes |
|---|---|---|
| Chairs | Agenda Bash | No bashing here, either. Getting lots of volunteers for pre-WGLC documents, that's great, we can never have too many, so please feel free to read them anyway. |
| Salvatore Loreto | IMS Communication Service Identifiers | draft-loreto-sipping-3gpp-ics-requirements-00.txt Long discussion on this topic in Dallas, but just on mail thread. Now working with draft on 3GPP requirements. Identify "Communications Services" to route service signaling to correct AS, identify proper terminal and proper application inside terminal. Assume that only one media handling is possible, but this isn't true in multi-service architectures (audio in push-to-talk and standard calls). Particular media or set of media does not uniquely identify a service. Would like groupings of media to be visible to proxies, etc. Communications Service = media components + unique service logic. Presenting three requirements for CSID. CSID shall not adversely affect interop or limit SIP capabilities. Should be INFORMATIVE, SIP should still work if UA doesn't understand CSID. Presenting IMS requirements for CSID use, application requirements as well. Tom - if you have a CSID with several applications, how do you choose? Also need an application identifier ("application reference"?). Gonzalo - opportunity to influence 3GPP. Eric - multiple applications are multiple things - we have RFC 3458 text on this, with request URIs, don't sub-address (this is "message context"). "Must work this way" plus "must work if you have no clue" is inconsistent. Remember people can lie. Gonzalo - 3GPP concern is routing on the terminating network. Paul - struggling for months on understanding this. There are assumptions about the way things work that aren't in the requirements. Have looked at IMS requirements, but there's still more involved. At a loss to know the good answer until I understand this better. "Only have one CSID for a dialog, for the life of the dialog" is a big assumption. Multiple ways forward depending on the goal - is this IMS-only or something broader? If we want to more than a P-header, we need a model and an architecture that we don't have. PTT is the example, and PTT won't work if you use the media in a different way (thought you were doing regular audio). May not be one answer for all possible things. Martin Dolly - helpful to describe this in more detail, showing what is actually ocurring. Am assuming that this would not be limited to 3GPP if it goes forward. Gonzalo - they came to us for help in figuring that out. Andrew - vital that this work gets done here for interop reasons with non-IMS networks. See a very tight coupling between reaching a device and requesting service logic, and there are differences - interop problems if you don't decouple them. Which service provider are we requesting a service FROM? Initiator or receiver requesting service? More use case work needed. Marcus - similar to presence discussions a couple of years ago. "Service is concatenation of capabilities in a PIDF document", but complicated services are hard to describe in a standardized way. If you have a device in the MIDDLE of the network, what is expected action here? Jonathan - perfect lead-in to relationship with presence. Presence can solve this problem for you. Intertwined with concepts of identity ("what is a SIP URI?"). Problem is that there are separate resources involved. Presence is about starting with a phone number and finding out what the capabilities of that phone number are (each with different URI). Don't construct URIs, learn them (works much better). Still interoperable and solves the problem that you have. Gonzalo - having multiple sessions in parallel, or sequentially, or ...? Can be in parallel. Could have to use both applications in your terminal? If they are both built on the same service logic. Paul - would really help to have more examples. Two data points" aren't enough to extrapolate from. Marcus - using presence to learn URIs works, but what if you don't know how? then nothing works - but it's like calling someone without a phone number. "Push to talk has to work without presence" - Jonathan did a very polite rave on "has to work without a header field" . But then you need the infrastructure? Sure - you need the needed mechanism to solve the problem. Is this a simple problem that can be solved without presence? Some discussion about "no". Andrew - 3GPP or OMA would not like presence service to solve this problem, but something similar might help. POC is not a good example, could identify POC requests from SDP. More like IM service logic selection - tackle that example. Want interaction with basic IM clients that don't understand advanced service. Roni - what is not clear is the expectation - is this like stimulus-based, or callerpref, or .... need to understand the requirement. Using presence is more like stimulus-based. Rohan - how many people understand requirements after discussion? Four or five. Don't spend more time talking about this if so few people understand requirements. Paul - Jonathan's point, reinterated in various ways - put CSID in, call goes somewhere, they understand it or they don't - Jonathan's suggestion is make the call or not. Jonathan - yes, and ties into interop issue. If you are in IMS or OMA and don't care about interoping, do this. If you care about communicating with someone who doesn't agree with your definition of IM, do something else. Andrew - don't have caller say "invoke this in another network" if the other network doesn't support it. This is a cookie-cutter thing that won't actually happen. Need interop for basic service, let people go crazy on top of that. Must guarantee you can call most of the people in the rest of the world. Gonzalo - please add use cases and examples. |
| Richard Ejzak | Early Media Authorization | draft-ejzak-sipping-p-em-auth-01.txt Gonzalo - this is based on expert review of a P-header that might or might not be changing fundamental behavior, as discussed on mailing list. Some RFCs say early media can flow immediately on signaling SDP, others say it won't be rendered - conflicting. PSTN talks a lot about early media, based on billing in ISUP. There is no terminating switch to police this in a SIP network, in the general case. Local policy options - some disallow early media for a variety of applications. What media to render prior to answer? Unclear how to prioritize various sources of early media, need flexibilty of local policy. How to turn off unwanted sources? Problems with muting - how do we know intention? How do we know who to mute during forking? More media clipping with muting than with media blocking (need another offer-answer exchange). Blocking has problems with RTCP, forking, etc. RFC 3960 has recommendations on early media, but these break down under forking, early media priority, billing policy for early media (TISPAN problem). Draft focuses on narrow problem with transitive trust model. Have gotten significant objections because UAS does not know when early media blocking occurs - think this is strange because network may block without header anyway, no guarantee early media will be rendered anyway. There are rejected alternatives to draft already. Gonzalo pointed out on the list that header isn't needed if blocking policy happens at private network border. Are there additional problems to be solved? Allow UAS to discover if early media WILL be rendered? Would solve existing problem separately from early media authorization, allow existing draft to proceed. Eric - on slide 14, remember why things were done in PSTN, misbehaving user agents don't fail correctly. Think the "early media rendering discovery" is the real value. CRBT isn't the right example, if you allow CRBT you have no incentive to allow media to flow BACK, don't need a header to make this happen. Brian - Not about user agents, about between proxies in a private network (also applies to Eric's point). But people will use this from UAs - not true? No, because proxies police this header (in my network, but it's a private header). But this will confuse devices, even proxies. Why send multiple media streams when you know which one should be rendered? Why do you need a header for this? Want to keep this simple as possible. Don't want to force network to care about this stuff. Shouldn't leak out to UAs, it will confuse them. Hadriel - forking before the border, right? With responses from other proxies. SBCs do this stuff but we don't want to. SBC doesn't know whether to suppress media or not. Specs don't require you to render early media in any case. Not that complicated, it's a private header, what's the problem? Adam - well-written, well-scoped draft solving problems that have been solved in more destructive ways. Publish this and deprecate more destructive ways. Paul - messy area, reasonable people can differ. P-headers should "first do no harm". Is there harm? Does early media ever work? Answer may be "not unless you have information beyond what SIP can tell you". This is broken. Shouldn't have early media, or if we have it, we should make it work. If this call is from a network that uses this and traverses an untrusted network on the way to a gateway, announcements get lost. Why would this work if the gateway is from your network and not otherwise? Richard Barnes - early media poses lots of problems, especially in security. RTPSEC throwing away a lot of SIP mechanisms here. Why not treat this as a race condition and fix it? "Telephone networks" assume early media. How much of the PSTN is SIP supposed to replicate? Dale Worley, slide 13 - who rejected these approaches? Richard, on behalf of TISPAN. Dean Willis - early media is my fault, this relates to forking and interaction with broken PSTN. We knew at the time this didn't work with forking. Early media is completely broken and intractable. We know enough to define PSTN interworking that doesn't require early media (but PSTN is still billing on SIP signaling, after being told not to for nine years). Draft doesn't fix fundamental SIP problem, and we need to fix the problem. Richard - this is INFO header in a private network. Does not change guarantees about early media today. Dave Oran - how many hours have we spent on problems with early media during the last nine years? Ban early media and ban billing off SIP 200 OK. Martin Dolly - can describe services that require early media all night long. American Idol. FCC will mandate early media support. Rohan - we've been talking about billing interaction here since before there was SIP. You have a channel. That solves a ton of problems. Don't object to draft, doesn't seem to cause harm, could care less. Applications which use early media for two-way are just evil. Francois - 200 OK would melt down when you go to a PSTN gateway as one of the alteratives in forking. Brian - debate over "harm" is misleading because there's a bigger problem that's not being solved and this will be misused in inappropriate ways, outside private networks. Aki - not an expert, but we have a concrete proposal that has been countered with nothing. Send text on how to fix the problem. Gonzalo - applicability statement is IMS-only, no parallel forking. Is there a useful solution with these restrictions? Richard says "no perfect solution", but yes, would be useful within a private network. Hum to go ahead scoped as a P-header, not a general solution? 30-40 OK, uncomfortable? fewer. Ben - going ahead with general solution? not precluding general solution. Dean - P-Asserted-Identity was ALSO a train wreck... |
| Jonathan Rosenberg | Overload Requirements | draft-rosenberg-sipping-overload-reqs-01.txt draft-hilt-sipping-hopbyhop-overload-00.txt draft-malas-sipping-congestion-header-01.txt 503 creates MORE traffic in congestion, especially when retransmits of INVITEs are lost. Good support in Dallas, revised document based on discussion. Underutilization is also a problem - 503 intended for server farm. Need guidance on scope of overload, SIP message priotization. Clarify guidance on prioritzation as local policy matter. "USEFUL throughput"... Don't award non-implementers. Many other clarifications. Steve Norris - What messages are sent between overloaded clusters? Requirements draft remains individual because we don't have charter milestone - parked. Solutions drafts don't have same design space. 0-5 or 0-100? How information is sent upstream? Scope of applicability? Retry-after, or new header field. Diagnostics? from more than one hop away. Henning - interaction with QoS routing problems, oscillation, etc. Volker - can actually avoid congestion collapse with mechanisms like this - but do you have oscillation? or poor utilization? Hadriel - problems from simulation is that oscillation is based on sender strategy - do we standarize sender behavior? this is Big Issue #1, like TCP. Janet Gunn - how quickly do I respond to indicators of overload? Hysteresis, not sure how much tuning is local policy. TCP doesn't have these problems, because we all know when it sends indications of loss. Martin Dolly - very supportive of this approach, need well-defined behavior and provisional sending values (depend on deployments). Must work when you don't know the network topology. Alan - we have a really complex system, this can get ugly, I'm not a control system engineer. Jonathan - agree, we talked to TSVWG on this previously, need to review before "the end" - first versions, etc. Can we get someone assigned? Steve Norris - separate protocol, or SIP itself? TISPAN thinks it's a separate protocol - losing information during overload, but Jonathan doesn't want to limit scope to managed networks. Henning - worried when I hear "we need lots of knobs being used" - means operators can't make it work in real networks. Worried that tightly-controlled networks have lots of tools, we need to allow for loosely-controlled networks (not just RSERPOOL). Allison - two points. Can you characterize any of this as application multicast? That has an effect. Can you show overload data to people who look at algorithms? Algorithm choices depend on deployment situations - need to help researchers choose right parameters. Is there admission control? This also makes a difference. Need to get information about "need to work in this environment" constraints. Volker - goal is to avoid congestion collapse, throughput improvement is secondary. Vijay - there are two proposals, would like to have one when we move forward. People met for first time here. Steve Norris - probably have not done simulations as applications multicast, but have published results in other forums. Don't know how to publish as an RFC. Spencer- interaction with TCP mechanisms, also needs to be considered. Janet - must make sure we don't make the problem worse - send header back on 100 message may not work well in congestion case. |
| Daryl Malas | SIP Performance Metrics | draft-malas-performance-metrics-03.txt Huge problems in discussions with vendors and operators. No standard terms, metrics, methods, current reliance on PSTN metrics... Got a lot of feedback from inside/outside IETF. SIPPING/BMWG/SPEC/ITU-T, with different motivations and charters. What would SIPPING role be? Would be great to have consistent terminologies and metrics. Have slides on proposed metrics. Need to identify persistent problems as opposed to transitory problems. Is this even SIPPING work? Should this be a working group item? Certainly need consistent set of terms. More metrics? Less? Media performance? SIP MIB incorporation? Henning - good to know someone cares about performance (now) - different communities want different performance metrics for different reasons. Don't think we want to come up with SLA view, but stuff may be used in SLAs. Interaction with SPEERMINT when you have two peers and want to compare them. Sohel - very imporant, we like it. Tom Taylor - want to reinforce Henning's point. Must define requirements for specific tasks and then the metrics that go with those requirements. Scott - BMWG is having problems scoping this work, biggest challenge to getting started. Could create 100 different metrics. Should we agree on a common (sub)set of metrics? Hum - working on measuring performance-related issues is interesting? Consensus in the room that this was interesting. |
| Martin Huelsemann | Call Completion Service in TISPAN | draft-poetzl-sipping-call-completion-00.txt Is ETSI-TISPAN - services are CCBS and CCNR ("busy subscriber" and "no reply") Call completion service on queue basis. should be coordinated and ordered as FIFO queue. Call completion calls have higher priority than normal calls. Should be based on existing SIP means, simple, interoperable with PSTN call completion solutions. Open issues... Indication that subscription is needed? - Allow-events header in 486 or 180 responses. Capability of management of call completion queues - use SUBSCRIBE/NOTIFY with two new event packages (CCBS and CCNR). Gonzalo - OK to manage remote queue? This is like floor control. Miguel - Could be more generic problem being solved. Keith - this is not a queue. It's reordered based on an undefined algorithm. Alan Johnston - interesting, could be used for other stuff. Robert - purist version of SUBSCRIBE/NOTIFY is that you're observing, but SUBSCRIBEing changes state. Not a problem if you're clear about this when you define it. Prioritization of call completion calls - Propose P-Service-Indication header. Call flow is an eye chart... please look at slide 11 online :-) Will add explanatory text and signaling flow - need reviewing, comments, discussion. Gonzalo - please send comments to authors and mailing list. |
| Discussion Leader | Topic | My
Notes |
|---|---|---|
| Gonzalo and Mary |
Agenda Bash | Is an official meeting of the
SIPPING working group, Note Well applies. No agenda bashing. Goal is to BOF in San Diego and form a working group afterwards. |
| Dean Willis |
Concepts and Terminology | draft-willis-p2psip-concepts-00.txt BOF in Dallas, crashed and burned in flames. David, Eunsoo, Phillip, Henning, Cullen, Dean on 80 hours of conference calls plus side calls. Doing P2P-SIP, not P2P-DNS, etc. Dean described P2P-SIP overlays from the draft. We drop "network" from the discussion because we're only talking about overlays. P2P-SIP Peer may forward SIP requests to other entities. We drop "supernode" from the discussion because it's not helpful. Clients use the overlay without providing storage and retrieval services. Brian - how do you address the client without a unique identifer? You don't, you address the user of the client. Per-SIP User Agent is coupled to a P2P-SIP Peer or Client. P2P-SIP User does have a unique identifier within the overlay that is the moral equivalent of an AOR. P2P-SIP Node Roles - there are quite a lot of them. Scott Brim - Client "uses but do not participant" - seems inconsistent with slide - point is that clients don't contribute resources that are used by other elements - needs to be clarified. Client does not participate in DHT, for example. Keith - first few slides are general rendezvous protocol requirements - are we going there again? Dean thinks this is a great idea for another BOF but not P2P-SIP. Although it is fair to say that at least half the problem is solving the rendezvous problem. "Enrollment vs insertion" - Enrollment gives you ability (ID and credentials) to participate in the overlay. Won't specify mechanism for enrollment here, but will specify the results of enrollment. David - difference is that enrollment happens once/ever, insertion is anytime you turn a UA on. EKR - only peers can serve? May still have contact association for a user, etc. "Adding routing information" or "adding information"? What about a network where enrollment is not necessary? Ad hoc with no credentials? Would be an open question. "Working Diagram" is an eye chart, but it's easier to read in the slides than in the draft. Philip cares about peers behind NATs. Philip - outbound got deleted from our document. Assume that we do ICE, TURN, etc... like anything else. Scott - treating peer and client as exclusive functions, and they aren't - don't make them look so exclusive. Philip - there's a superset of functionality. Eunsoo - confusion because we forgot to say peers have the client functionality as well. |
| David Bryan |
Discussion of charter |
Big top-level questions that
have surfaced in debate. What gets standardized? Two protocols - an overlay client protocol and an overlay peer protocol. Could be the same protocol, but don't know that yet. At least one could be vanilla SIP, but don't know that yet, either. Greg - SIP part of P2P-SIP is when you know location and can send INVITEs, etc. Humm on this? Cullen - need to focus on building the charter - for the BOF? Cullen would like to do another BOF for RAI reasons, but we're working on a charter for the working group. EKR says BOF again would be good. Humm on "What are we standardizing?" lots of hands are OK, 80 percent. Disagree? none in this room. Are topologies with NATs in scope? 3 subquestions - at all? locating media relays for NAT traversal? reuse existing IETF work? Keith - what's the baseline? will work through as many as we can. there are at least 15 levels of NATs out there at various levels of evil. Cullen - we're not talking about BEHAVE-compliant NATs, because ICE would work Spencer - rant on whether you need to answer this question in order to have a working group chartered Greg - our customers ask about NATs immediately. Philip - we need to do this from the start. Spencer - but how much do we need to say about NATs in order to charter the working group? Henning - TURN and ICE, or more interesting non-IETF NAT traversal? Would be a lot more controversial. Cullen - you're right, putting this over signaling wasn't the key thing, it was over TCP over HTTPS over a media relay. ICE went there. Pick well-defined bars. Don't worry that we're missing a lot here. Our NAT-virginity is long gone here. Henry - developers and customers care exactly about this chart, exactly as it is. Take a vote. Eunsoo - we're not overlapping with any other NAT traversal work. Humm - "yes" before we asked the question - wording in the charter on reusing ICE, etc. Almost unanimous on the chart. Disagree? Keith - will pass requirements for changes to other protocols to appropriate groups. Can we limit the scope to name lookups? Proposed answer: Yes. Very analogous to SIP registrar functionality. Dean - how does this play with "find the media relay"? As long as the media relay has a name. Alan - this isn't about SIP registrar, it's about location service. Gonzalo and Dean had a short clarifying chat. "Provide search functionality" - out of scope for this discussion. Not path-optimal, just has to work. Greg - if we have a predictable name for a resource, that would be easier than searching across the entire network. Not trying to match something that's ephemeral - just like looking up a SIP URI now. David - have to be able to find by name, even if the name is predicted. Dan Petrie - could just look in an LDAP server and bootstrap the search that way. Henning - this is about DNS-style lookups (in scope) vs LDAP-style lookups (out of scope). Three levels of looking, like NTP-style, hard part is smallest angle of a triangle is out of scope. David - not tied to P2P, either - also useful to CS. Philip - looking up a user, could be at multiple locations. Media relay could work the same way if you have multiple relays. Greg - if you can get a canonical URL, you could look up anything in DHT. Not saying what is verboten, only what is in scope for the chartered working group. EKR - focus on the bottom layer first. Philip - previous version of charter had two types of "out of scope" - this is stuff that would come in scope in a later version. All yeses for limiting scope to name lookup. Anonymization service? SIP needs this but no answer today. Do it here? Could be complicated. Spencer - is this required for the very early work? David is asking the same question. Greg - very important service, bad idea to tackle this now. Contain complexity now. Personally think that it won't take much. Hannes - this is complicated today because we don't know what that is. Keith - thought RFC 3323 defined this - what's going beyond this? EKR - incredibly hard to do this, protocols leak information like crazy, need to think about this up front rather than add this in later. Dan Petrie - don't think an anonymization service is ever a requirement. Don't add early complexity for something we might do later. People who need this should pay price for complexity. We can add this to the charter later. John Elwell - anonymization is difficult to achieve - security? Philip - not interested in this personally, there are things we've put out of scope because know how to add them later. Who is interested? Between now and BOF, think about how to add this later on? Jon - with a system like this, building security is a war against anonymization. You won't be adding things, you'll be taking things away. Don't understand "this adds complexity", as part of this discussion. Cullen as individual - have gotten requests from IEPREP chairs about standard SIP with anonymization - don't reveal where you are when you make an emergency call. You guys don't deserve to have this problem dumped on you, but you're the only likely stuckees. Greg - I am most opposed to this because there hasn't been sufficient discussion about how/to what end anonymization would be achieved. Process objection - don't distract people from getting core work done. Eunsoo - would like to have this from beginning but don't know how to solve it now. Dean - is very important, but delivery could be handled separately - "nothing that precludes" would be sufficient. Don't put in initial charter. Jon - good plan for "get a charter and a WG", but if you don't understand anonymous, you won't understand security, either - opposite sides of same coin. Philip - between now and San Diego, someone could put a draft out on this? Hannes - don't understand but do work in this environment - it's not black and white, there are lots of possibilities. Look at MIP, they have same problems now. More precise is helpful. EKR - agree and would be willing to sit down with someone and help. Interested at all? 15 against, 30 for. Exclude completely? 8 for. Dean's compromise? 40 for. Include in charter? none for. Keith - this is fundamentally bound up in SIP, can't fix without changing SIP. Gonzalo - this will go through SIP change process. Hannes - Don't want 50 milestones, start with threat analysis, etc. and discover what needs to be done (after chartering). Gonzalo - don't focus beyond a successful BOF in San Diego - can always add later. Henning - trust admission control, or worry about rogue elements? Start with trusting the enrollment process. Dean - assume rogue elements, at least some. SIPSEC thread about changing SIP so proxies don't see everything. Fine for CS-SIP, but much scarier here. Henning - not saying we trust proxies, saying supernodes won't randomly disrupt the DHT. Dean - "a" node doing bad things is easy to worry about - 50 percent is harder. EKR - as we move to threat analysis... malicious can be disrupting DHT, rerouting calls, etc. State of the art is "somewhat resilient to damage". David - make sure we have strong security metrics in place. Security and identity more entangled in P2P deployments. Centralized certificate authorities, but not for every scenario. Cullen - charter with explicit security tradeoffs, don't extend the state of the art (this is the IETF), but think about what tradeoff looks like. Greg - threat model as milestone would be reasonable to include in the proposed charter. Philip - we have an hour left - can you get agreement on a charter proposal here? David - don't do that, talk about what we agree on? Philip - we have two versions of draft text, not wordsmithing and not from scratch. Eunsoo - would like to charter ASAP, but we made progress today, go to mailing list and talk to people who couldn't be here. ??? Michael - we had two near-unanimous votes, let's get things done. Cullen - let's declare success and go peer-to-peer. Adjourned.... at about 2 PM. |